home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 58 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.8 KB  |  77 lines

  1. Newsgroups: comp.std.c
  2. Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
  3. From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
  4. Subject: Re: Undefined result vs. int's holding undefined values.
  5. In-Reply-To: Daniel Wood's message of 8 Jan 1996 22:00:32 GMT
  6. Message-ID: <KANZE.96Jan9115946@slsvewt.lts.sel.alcatel.de>
  7. Sender: news@lts.sel.alcatel.de
  8. Organization: SEL
  9. References: <4ck70b$rd7@news.informix.com> <4ckms5$rd7@news.informix.com>
  10.     <4cmg0s$1mb@der.twinsun.com> <oZA8wQ9ytpjN084yn@csn.net>
  11.     <4cs460$d6e@news.informix.com>
  12. Date: 09 Jan 1996 10:59:45 GMT
  13.  
  14. In article <4cs460$d6e@news.informix.com> Daniel Wood
  15. <dwood@informix.com> writes:
  16.  
  17. |> I totally understand what you are doing in the above but this would have to
  18. |> be the ultimate in a cheap out for a vendor.  SCO could claim that before
  19. |> ever looking at a test case containing a suspected compiler bug that every
  20. |> arithmetic calculation would have to first have a test similar to the above
  21. |> to protect against overflow/underflow.  Does an appropriate "SAFE TEST" exist
  22. |> for multiple.
  23.  
  24. Yes, but you have to do the actual operations using the absolute
  25. values, and then generate the sign yourself.  Basically, for positive
  26. values, x * y will overflow if and only if x > y / INT_MAX.  (You must
  27. use positive values because division with negative values is not well
  28. defined, and if the result will be negative, the test must use
  29. -INT_MIN instead of INT_MAX.)
  30.  
  31. |> Has anyone actually seen a real production program where every
  32. |> calculation was protected against overflow/underflow.
  33.  
  34. Yes.  In the late 80's I worked on a Basic interpreter where all
  35. overflows generated a run-time exception.  Given the overhead of the
  36. interpreter, and the type of applications that were being written in
  37. Basic, the overhead for checking was perfectly acceptable.  Although
  38. the code was written before ANSI introduced the concept of `undefined
  39. behavior', it was written such that an integer overflow could never
  40. occur, even in results that would later be thrown out (because of
  41. error detection).  It's not particularly hard; all that is needed is
  42. 1) that the requirements require it, and 2) that the performance
  43. penalty is acceptable.
  44.  
  45.     [...]
  46. |> Do any machines exist which actually explode when you add two number together
  47. |> such that the result would exceed MAXINT? :-)  Get pratical!
  48.  
  49. Explode, perhaps not.  But a core dump would be an appropriate
  50. behavior.  Most programs don't check for overflow on the grounds that
  51. garbage in/garbage out is an acceptable modus operandi.  Practically,
  52. overflow cannot occur for reasonable values of input, and they
  53. consider undefined behavior acceptable for unreasonable user input
  54. (given that in reality, we know that the undefined behavior won't
  55. actually cause loss of life or property).  In such cases, overflow
  56. represents a failure in the model; it would be nice to have the
  57. program fail if the model fails, rather than simply give wrong
  58. results.
  59.  
  60. |> I am particularly interested in the answer to my "safe multiply" question
  61. |> above.  It would be quite funny to find that there is actually no way to
  62. |> create, in a practical way, a safe c program that used multiple if the
  63. |> standard was followed to the letter of the law.  I have thought of a way
  64. |> but it would be alot more involved then the sum_overflow() check above.
  65.  
  66. It is somewhat more complicated than the above.
  67.  
  68. In most cases, the correct solution is *not* to test each individual
  69. operations, but to validate all input values for `reasonableness', and
  70. then prove that overflow cannot occur for reasonable values of input.
  71. --
  72. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  73. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  74. Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
  75.                 -- A la recherche d'une activitΘ dans une region francophone
  76.  
  77.